https://www.cnblogs.com/GrimMjx/p/10695512.html

https://www.cnblogs.com/huangxincheng/p/5010795.html

https://www.cnblogs.com/lukexwang/p/4699354.html

http://www.web-lovers.com/redis-source-aof.html

https://blog.csdn.net/opens_tym/article/details/10097805

https://zackku.com/redis-rdb-aof/

https://zq99299.github.io/note-book/cache-pdp/redis/009.html

http://remcarpediem.net

redis持久化的取舍和选择

持久化的作用

什么是持久化

redis所有数据保存在内存中， 对数据的更新将异步地保存到磁盘上

image-20190803142122503

持久化的实现方式

  • 快照
    • mysql dump
    • redis RDB
  • 写日志
    • mysql binlog
    • hbase hLog
    • redis AOF

RDB

什么是RDB

image-20190803142137744

触发机制-主要三种方式

  • save（同步）

image-20190803142147453

image-20190803143010255

1
2
3
* 文件策略：如存在老的RDB文件，新替换老
* 复杂度：O(N)
复制代码
  • bgsave(异步）

image-20190803142204499

  • 自动配置

image-20190803142212414

image-20190803143627442

**相关配置

配置参数 值
save 900 1
save 300 10
save 60 10000
dbfilename dump-${port}.rdb
dir /bigdishpath
stop-writes-on-bgsav-error yes
rdbcompression yes

save与bgsave

image-20190803142219868

触发机制-不容忽略的方式

其他的方式也会触发生成RDB文件

  • 全量复制
  • debug reload
  • shutdown

总结

  • RDB是Redis内存到硬盘的快照，用于持久化
  • save通常会阻塞Redis
  • bgsave不会阻塞redis，但是会fork新进程
  • save自动配置满足任一就会被执行
  • 有些触发机制不容忽视

实战

image-20190803144108961

1
2
3
#默认情况下，Redis不作为守护进程运行。如果你需要，用“是”。
#注意，Redis将在/var/run/ Redis中写入pid文件。当监控pid。
daemonize yes
1
2
3
4
# Specify the log file name. Also the empty string can be used to force
# Redis to log on the standard output. Note that if you use standard
# output for logging but daemonize, logs will be sent to /dev/null
logfile "6379.log"
1
2
3
#save 900 1
#save 300 10
#save 60 10000
1
dbfilename dump-6379.rdb

image-20190803144454242

  • 启动

    image-20190803144855746

image-20190803144910374

image-20190803144947490

image-20190803144958824

AOF

RDB现存问题

  • 耗时，耗性能

image-20190803142229318

  • 不可控，丢失数据

image-20190803142237900

什么是AOF

  • 创建

image-20190803142245289

  • 恢复

image-20190803142253758

AOF三种策略

  • always

image-20190803142302433

  • everysec

image-20190803142310226)

  • no

image-20190803142318534

三种策略比较

image-20190803142324561

AOF重写

image-20190803142332962

AOF重写的作用

  • 减少硬盘占用量
  • 加速恢复速度

AOF重写实现的两种方式

  • bgrewriteaof

image-20190803142348803

  • aof重写配置

image-20190803142358986

image-20190803142406746

AOF重写流程

image-20190803142423212

配置

image-201908031424328021)

RDB与AOF的选择

image-20190803142442207

RDB最佳策略

  • 关
  • 集中管理
  • 主从，从开

AOF最佳策略

  • 开，缓存和存储
  • AOF重写集中管理
  • everysec

总结

进阶的Redis之数据持久化RDB与AOF

发表于 2018-11-02 | 分类于 Redis进阶

大家都知道，Redis之所以性能好，读写快，是因为Redis是一个内存数据库，它的操作都几乎基于内存。但是内存型数据库有一个很大的弊端，就是当数据库进程崩溃或系统重启的时候，如果内存数据不保存的话，里面的数据就会丢失不见了。这样的数据库并不是一个可靠的数据库。

所以数据的持久化是内存型数据库的重中之重。它不仅提供数据保存硬盘的功能，还可以借此用硬盘容量扩展数据存储空间，使得Redis的可以存储超过机器本身内存大小的数据。

Redis对于数据持久化提供了两种持久化的方案，RDB与AOF。它们的原理和使用场景都大不相同，下面我们来详细地了解下。

RDB——数据快照（Snapshot）

RDB，提供一个某个时间点的数据的Snapshot，保存在RDB文件中。它可以通过SAVE/BGSAVE命令手动执行，把数据Snapshot写到RDB文件，也可以通过配置，定时执行。

Redis也可以通过加载RDB文件，把数据从磁盘加载读取到Redis中。

RDB文件创建

连上Redis，设值一些值，然后执行SAVE命令。
image-20190803153203273

然后可以查看下redis.conf的持久化工作目录。进入目录可以看到保存了一个dump.rdb文件。该文件是一个二进制文件，无法直接正常打开。
image-20190803153154867

至于SAVE/BGSAVE的区别，就是前置是阻塞执行，此时服务不会接受请求，后者是Fork一个子进程出来，由该进程去执行保存RDB文件的操作，不影响用户请求。

P.S. Redis是单进程的，所以BGSAVE只能Fork一个子进程，而不是创建一个线程处理。

以上是手动执行的过程。但在生产我们很少会手动登上服务去执行操作，所以更多的时候是依赖Redis的配置，定时保存RDB文件。

打开redis.conf配置文件，找到SNAPSHOTTING的配置，Save Point的设置。
image-20190803153144116
图中的配置意思是，当至少有一个key变更时，900秒后会执行一次SAVE。其他配置同理，有10次变更，300秒后保存一次…..

在Redis中，这个自动保存RDB的功能是默认开启的。

RDB文件加载

先kill掉Redis进程，再重新启动Redis Server，会发现日志会有这样的一行，
image-20190803153133693

并且Redis中，依然有之前设置的三个值。说明Redis在启动的时候，会加载数据初始化。

不过，这里加载的初始化数据不一定是RDB的。如果Redis开启了AOF，会优先从AOF初始化数据，否则才会加载RDB的数据。

RDB优缺点

优点：

  1. RDB是某一时间点的快照，是一个紧凑的单文件，更多用于数据备份。可以按每小时或每日来备份，方便从不同的版本恢复数据。
  2. 单文件容易传输到远程服务做故障恢复。
  3. RDB可以Fork子进程进行持久化，使Redis可以更好地处理用户请求
  4. 在大量数据的情况下，RDB相比较于AOF会更快的加载。

缺点：

  1. 如果Redis不及时保存RDB文件，会造成数据的丢失。例如系统突然断电，但未来得及保存数据。即使你设置更多的Save point，也无法保证100%的数据不丢失。
  2. RDB经常需要fork子进程去执行，但如果再大量数据的情况下，这个fork操作会非常耗CPU资源的。对比AOF虽然也是fork，但是它的数据保存处理是可以控制的，不需要全量保存。

AOF——日志追加（Append-Only）

Redis的另外一种持久化方案就是AOF，Append Only File。AOF相当于一个操作的日志记录，每次对于数据的变更都会记录追加到AOF日志。当服务启动的时候就会读这些操作日志，重新执行一次操作，从而恢复原始数据。

AOF启用

AOF默认是关闭的。打开redis.conf配置文件，找到appendonly no改成appendonly yes。
image-20190803153122664
AOF和RDB是可以共存的，只要保存的文件名不冲突。

AOF fsync同步规则

配置文件往下拉，看到fsync的配置。
image-20190803153107254
fsync()是一个系统调用函数，告诉操作系统把数据写到硬盘上，而不是缓存更多数据才写到硬盘。这样的调用可以及时保存数据到硬盘上。

Redis提供了三种fsync的调用方式

  • appendfsync always，每次操作记录都同步到硬盘上，最低效，最安全。
  • appendfsync everysec，每秒执行一次把操作记录同步到硬盘上。默认选项。
  • appendfsync no，不执行fysnc调用，让操作系统自动操作把缓存数据写到硬盘上，不可靠，但最快。

AOF文件格式解析

开启AOF后，会再工作目录看到appendonly.aof文件。
image-20190803153052736
在客户端上执行一些命令后，打开AOF文件，可以观察到有对应的操作的记录日志。
image-20190803153043385
文件解析说明：

  • ，表示命令的参数个数，例如set a 1是三个参数，所以是3
  • $，表示参数的字节数，例如set这个参数是三字节，所以是$3，key值a是一个字节，所以是$1
  • 无符号，表示是参数的数据，例如set,a,1就是具体的数据

日志重写

AOF虽然比RDB更可靠，但缺点也是比较明显的，就是每次写操作都要把操作日志写到文件上，这样会导致文件非常冗余。

假若你要自增一个计数器100次，如果不重写，AOF文件就就会有这100次的自增记录，如INCR a。如果执行了日志重写，那么文件只会保留set a 100而不是100条INCR a。这样拥有相同的结果，但可以大大减少AOF的文件大小，并且可以让AOF载入的时候提升载入的效率。

看回redis.conf配置，有两项控制rewrite的选项。
image-20190803153020458

  • auto-aof-rewrite-percentage 100，当文件增长100%（一倍）时候，自动重写。
  • auto-aof-rewrite-min-size 64mb，日志重写最小文件大小，如果小于该大小，不会自动重写。

来实验一下重写的结果，我们先设定一个a值，然后自增多次，查看AOF文件内容。里面有很多INCR的语句记录
image-20190803153008148

然后我们手动执行下BGREWRITEOF，执行日志重写。
image-20190803152958350
可以看到，多个incr语句，变成了一个set a 6语句，减少了5个incr a语句的操作日志。

AOF优缺点

优点：

  1. AOF可以设置 完全不同步、每秒同步、每次操作同，默认是每秒同步。因为AOF是操作指令的追加，所以可以频繁的大量的同步。
  2. AOF文件是一个值追加日志的文件，即使服务宕机为写入完整的命令，也可以通过redis-check-aof工具修复这些问题。
  3. 如果AOF文件过大，Redis会在后台自动地重写AOF文件。重写后会使AOF文件压缩到最小所需的指令集。
  4. AOF文件是有序保存数据库的所有写入操作，易读，易分析。即使如果不小心误操作数据库，也很容易找出错误指令，恢复到某个数据节点。例如不小心FLUSHALL，可以非常容易恢复到执行命令之前。

缺点

  1. 相同数据量下，AOF的文件通常体积会比RDB大。因为AOF是存指令的，而RDB是所有指令的结果快照。但AOF在日志重写后会压缩一些空间。
  2. 在大量写入和载入的时候，AOF的效率会比RDB低。因为大量写入，AOF会执行更多的保存命令，载入的时候也需要大量的重执行命令来得到最后的结果。RDB对此更有优势。

如何选择

以上已经基本了解过RDB和AOF的使用、基本原理以及对应的优缺点。那么在实际当中，我们到底怎么去选择用哪种持久化方式呢？

一般来说，不考虑硬盘大小，最安全的做法是RDB与AOF同时使用，即使AOF损坏无法修复，还可以用RDB来恢复数据。

如果Redis的数据在你的服务中并不是必要的数据，例如只是当简单的缓存，没有缓存也不会造成缓存雪崩。说明数据的安全可靠性并不是首要考虑范围内，那么单独只使用RDB就可以了。

不推荐单独使用AOF，因为AOF对于数据的恢复载入来说，比RDB慢。并且Redis官方也说明了，AOF有一个罕见的bug。出了问题无法很好的解决。所以使用AOF的时候，最好还是有RDB作为数据备份。

image-20190803152948048
根据官方的意愿描述，在未来可能会有一种RDB与AOF相结合的持久化模型。到时Redis持久化就不再如此麻烦费劲了，我们拭目以待吧。

RDB

image-20190803153722433

image-20190803153903964